REMARKS 

Applicants have amended claims 3, 5 5 7 16, 17, 19, 21, 31 and 32 and cancelled claims 
14, 33-36 from further consideration in this application. Applicants are not conceding in this 
application that those claims are not patentable over the art cited by the Examiner, as the present 
claim amendments and cancellations are only for facilitating expeditious prosecution of the 
allowable subject matter noted by the examiner. Applicants respectfully reserve the right to 
pursue these and other claims in one or more continuations and/or divisional patent applications 

The Examiner objected to claim 21 because of the following alleged informalities: 
Claims 21 recites "a simulated serial cores." The claim should recite "a simulated serial core." 
Applicants have so amended claim 21. 

The Examiner rejected claims 2, 3, 5, 7, 14, 16, 17, 19, 21 and 31-36 under 35 U.S. C. § 
101 because the claimed invention is allegedly directed to non-statutory subject matter. 

The Examiner rejected claims 2, 3, 5, 7, 16, 17, 19, 21 and 31-36 under 35 U.S.C. § 1 12, 
second paragraph, as allegedly being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. 

In an interview between Examiner Saif Alhija and Applicants representative Anthony 
Palagonia held on May 16, 2007, the Examiner suggested changes to the construction of claims 
3 1 and 32 that would overcome the 35 U.S. C. § 101 and 35 U.S.C. § 112, second paragraph 
rejections. Further, it was agreed that the term "programmably connectable" was acceptable. 
Applicants believe they have incorporated those changes into claims 31 and 32 and that claims 
31 and 32, as amended, are not rejectable under 35 U.S. C. § 101 and 35 U.S.C. § 112, second 
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paragraph. Since claims 2, 3, 5 and 7 depend from claim 31 and claims 16, 17, and 19 depend 
from claim 32, Applicants believe claims 2, 3, 5, 7, 16, 17 and 19 are likewise not rejectable 
under 35 U.S. C. § 101 and 35 U.S.C. § 112, second paragraph. The 35 USC 102(b) and 103(a) 
rejections were also discussed, but no agreement on patentability was reached. 

The Examiner rejected claims 2, 3, 5, 7, 14, 16, 17, 19 and 31-36 under 35 U.S.C. § 
102(b) as allegedly being clearly anticipated by Dearth et al. "Virtual Bus For Distributed 
Hardware Simulation", U.S. Patent No. 5,881,267, hereafter referred to as Dearth. 

The Examiner rejected claim 21 under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Dearth in view of Dutta et al. "Viper", hereafter referred to as Dutta. 

The Examiner rejected claims 2, 3, 5, 7, 14, 16, 17, 19 and 31-36 under 35 U.S.C. § 
103(a) as allegedly being unpatentable over Evans et al. "Apparatus and Method for Verifying a 
Multi-Component Electronic Design", U.S. Patent No. 6,279,146, hereafter referred to as Evans. 

The Examiner rejected claim 21 under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Evans in view of Dutta et al. "Viper", hereafter referred to as Dutta. 

Applicants respectfully traverse the § 102 and § 103 rejections with the following 
arguments. 
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35 U.S.C. § 102(b) 

The Examiner rejected claims 2, 3, 5, 7, 14, 16, 17, 19 and 31-36 under 35 U.S.C. § 
102(b) as allegedly being clearly anticipated by Dearth et al. "Virtual Bus For Distributed 
Hardware Simulation", U.S. Patent No. 5,881,267, hereafter referred to as Dearth, 

Since Applicants have canceled claims 14 and 33-36, the 35 U.S.C. § 102(b) of claims 14 
and 33-36 is moot. 

The following apply to each argument infra. Applicants note, in FIG. 3, Dearth et al, 
teaches a resolver 302 connected to virtual bus stubs 1 14A and 1 14B, which in turn are 
connected to respective, distributed simulation parts 1 12A and 1 12B. Dearth et al. teaches in 
FIG. 4, that VBS 1 14A includes an input register 404, an output register 406 and buffers 402 and 
408. Applicants note that in FIG. 9 of Dearth et al, which illustrates and describes resolver 302, 
in detail, there is no switch indicated and resolver 302. The Abstract of Dearth et al. teaches the 
resolver 302 only "(i) collects data from the virtual bus stubs representing signals driven on the 
bus by one or more of the circuit parts, (ii) resolves the current simulated state of the bus from 
the collected data, and (iii) sends data representing the resolved current simulated state of the bus 
to the virtual bus stubs." Note the "signals" are not returned anywhere only the "resolved current 
simulated state of the bus" is returned. In fact, the signals transmitted to the resolver are not the 
simulated I/O signals driven on the bus but rather "data representing the I/O signals driven on the 
bus" and the signal returned by the resolver do not affect the state of the DSP. See col. 7, lines 
30-38 which states: "For every cycle of a simulated bus clock which controls access to bus 214 
(FIG. 2), VBS 1 14A (FIG. 3) transfers to resolver 302 data indicating the state of bus 214 (FIG. 
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3) as represented by VBS 1 14A (FIG. 3). The transfer of data representing the state of a bus 
from a VBS, e.g., VBS 1 14A (FIG. 3), to resolver 302 is sometimes referred to herein as 
'posting. 5 VBS 1 14A posts simulated bus signals at a time when changes in the state of bus 214 
(FIG. 2) has no effect on the state of circuit part 212A as simulated by DSP 1 12A (FIG. 3)." 

Applicants respectfully contend that Dearth does not anticipate claim 31 or claim 32, as 
amended, because Dearth does not teach each and every feature of claims 3 1 and 32. For 
example, Dearth does not teach any of the following claim elements: 

(1) "code representing (i) an external memory model connected to a simulated external 
memory mapped test device and to said simulated memory controller." Applicants believe the 
Examiner relates the resolver of Dearth et al. to Applicants simulated external memory mapped 
test device and simulation systems 1 16A and 1 16B to Applicants integrated circuit design. 
Applicants note there is no teaching in Dearth et al. of "an external memory model" no less "an 
external memory model connected to a simulated external memory mapped test device." 
Applicants "external memory model" is not part of the Applicants "integrated circuit design" or 
Applicants "external memory mapped test device" so Dearth et al. does not even teach the same 
number of components as Applicants claim. Dearth teaches and shows in FIG. 3 that the 
resolver is only connected to the simulated systems. 

(2) "one or more first external I/O driver models connected between said simulated I/O 
cores and said simulated external memory mapped test device." Applicants find no teaching of 
"one or more first external I/O driver models" no less "one or more first external I/O driver 
models connected between said simulated I/O cores and said simulated external memory mapped 
test device" in Dearth et al. "Applicants "one or more first external I/O driver models" are not 
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part of the Applicants "integrated circuit design" or Applicants "external memory mapped test 
device" so Dearth et al. does not even teach the same number of components as Applicants claim 
Again, Dearth teaches and shows in FIG. 3 that the resolver is only connected to the simulated 
systems. 

(3) "one or more second external I/O driver models connected between a simulated 
switch of said simulated external memory mapped test device and said I/O controller " 

First Applicants point out that "one or more second external I/O driver models" are not 
part of the Applicants "integrated circuit design" or Applicants "external memory mapped test 
device" so Dearth et al. does not even teach the same number of components as Applicants claim 
Again, Dearth teaches and shows in FIG. 3 that the resolver is only connected to the simulated 
systems. 

Second, Applicants have pointed out supra, that there is no "switch" in the resolver of 
Dearth et al, FIG. 9 of Dearth et al. teaches counters '^02 and 904, buffers 906A-D and 908A-D, 
a hold list 916, data files 912 and 914, and resolving logic 914. Resolving logic 910 is illustrated 
in FIG. 13 of Dearth et al. and it can be seen it operates on data from registers 1302 and 1304 to 
produce data stored in register 1306. This data is then returned to the VBS. No bus connections 
no less connections to "said I/O control" have been switched. The only thing that has occurred is 
data has been logically processed. The results of the processing always go to the same place, 
namely the VBS if there is one or all the VBS's if there multiple VBS's. 

(4) "said simulated switch programmably connectable to said one or more second 
external I/O driver models in response to computer-executable instructions in a test case." As 
pointed out in (3) the input and out connections to logic 910 have not been switched, only data 
has been logically processed. Further, logic 910 of Dearth FIG. 13 besides being not a switch, is 
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also not capable of being "programmably switched." It can perform only one function 
determined by the logic gates and their connections. 

(5) "said test case comprising said list of computer-executable instructions for said 
simulated processor into said external memory model, said instructions describing selection of 
one or more simulated I/O cores and corresponding second external I/O models, allocation of 
pins of said I/O controller to selected simulated I/O cores and switch positions of said simulated 
switch to connect said corresponding second external I/O models to said I/O controller." There 
is no teaching in Dearth et al. that the testing involves "selecting one or more simulated I/O cores 
and corresponding second external I/O models" or "allocation of pins of said I/O controller to 
selected simulated I/O cores" or selecting "switch positions of said simulated switch to connect 
said corresponding second external I/O models to said I/O controller." 

(6) "allocating and connecting I/O pins of said simulated I/O controller to one or more of 
said simulated I/O cores" Dearth et al. is silent as to I/O pins. 

(7) "connecting said simulated external memory mapped test device to said simulated I/O 
controller through said corresponding second external I/O models." Again, Dearth et al. is silent 
as to "second external I/O models." '[ 

(8) "outputting said data representing a response of said computer simulation model of 
said integrated circuit design to said test casejo another computer readable media or another 
computer, (ii) display said data representing a response of said computer simulation model of 
said integrated circuit design on a computer screen, or both (i) and (ii)." Applicants point out 
that there is no data output outside of the simulation of Dearth et al. Dearth only teaches sending 
"data representing the resolved current simulated state of the bus to the virtual bus stubs" which 
are within the simulation systems 1 16A and 1 16B of Dearth et al. FIG. 3. 
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Based on the preceding arguments, Applicants respectfully maintain that Dearth does not 
anticipate claim 31, and that claim 31 is in condition for allowance. Since claims 2, 3, 5, 7 and 
21 depend from claim 31, Applicants contend that claims 2 5 3, 5, 7 and 21 are likewise in 
condition for allowance. Since claims 16, 17 and 19 depend from claim 32, Applicants contend 
that claims 16, 17 and 19 are likewise in condition for allowance. 
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35 U.S.C. § 103(a), claims 2, 3, 5, 7, 14, 16, 17, 19 and 31-36 

The Examiner rejected claims 2, 3, 5, 7, 14, 16, 17, 19 and 31-36 under 35 U.S.C. § 
103(a) as allegedly being unpatentable over Evans et al. "Apparatus and Method for Verifying a 
Multi-Component Electronic Design", U.S. Patent No. 6,279,146, hereafter referred to as Evans. 

Since Applicants have canceled claims 14 and 33-36, the rejection 35 U.S.C, § 103(a) 
rejection of claims 14 and 33-36 is moot. 

The Examiner has stated that "Evans does not explicitly disclose that every component is 
a simulated component representing the I/O controller, I/O cores, EMMTD, switch, I/O driver 
models, and bus. However Evans teaches that software verification is an order of magnitude 
slower than hardware verification, therefore, the process of verification is improved by 
implementing certain components in hardware. This not only teaches the use of software 
verification for components and packages but also that the implementation discussed in Evans is 
a step forward in the art by increasing the speed and therefore decreasing the time of verification. 
The implementation discussed in Evans reads on the implementation discussed in the claims of 
the instant application. (Evans. Column 1, Lines 31-39 for example) It would have been obvious 
to one of ordinary skill in the art to implement the verification in Evans by utilizing software 
instead of hardware in order to debug software prior to construction of the system being verified. 
(Evans. Column 2, Lines 30-32)." 

First Applicants respectfully submit that the Examiner has not interpreted the teaching of 
Evans et al. as to software verification being slower than hardware verification. The software 
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that Evans et aL is referring to is the application that an ASIC chip design runs and is not a 
software model of the chip design and simulated external I/O driver models, external memory 
model and external memory mapped test device of Applicants claims 3 1 and 32. 

Evans et al. in col. 2 lines 1 through 1 1 states; "Because much of the hardware in a 
system-like this is designed to work with specific software, this requires that both the hardware 
and software be developed together. Unfortunately, software verification requires an order of 
magnitude more simulation patterns to verify than does hardware verification. There is currently 
no means of running these verification tests until a hardware prototype of the system exists, 
typically at the completion of hardware design. If a hardware error is uncovered during the 
software testing, it forces a difficult decision between a very expensive change to the finalized 
hardware design or a cumbersome, and perhaps slow, software work- around." It is clear that 
"software" as used by Evans et al. means an application that "hardware" is intended to run and 
"software" is not a computer simulation model of an integrated circuit design. Further, it is clear 
that "hardware" as used by Evans et al. means an integrated circuit chip design. The term 
"hardware" when used alone by Evans et al. should be distinguished from the term "hardware 
model." In Evans et al. "hardware model" means a physical entity e.g., a hardware simulation 
(as opposed to a software simulation) of the integrated circuit design. The "hardware model" is a 
programmed FPGA, which models the integrated circuit design. It is the programmed FPGA 
that is simulated in Evan et al. The Examiner has acknowelged that the hardware model is a 
physical entity when the Examiner stated "Evans does not explicitly disclose that every 
component is a simulated component." 

Evans et al. in col. 2, lines 30-36 state: "Alternatively, the debug package could be used 
without the hardware components. This will, of course, not find problems that occur in the 
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interaction of the software and the hardware. The early use of such a debug package would be 
tremendously beneficial to software developers in their efforts to debug software prior to the 
time when an entire system has been constructed." Again, it is clear Evans is referring to an 
application by his use of the term software. He is stating that debug package of his invention 
which tests the integrated circuit design along with the application can be used to test just the 
application. Evans et aL is not stating that "hardware models" can be replaced by software 
simulation models. 

Evans et al. in col. 3, lines 5-14 states: "One recently released product is targeted at 
taking a microprocessor IC or bonded out core and connecting it to an event-driven simulator, 
utilizing software debugging tools to allow hardware and software designers to use a real 
hardware model of the core processor during system design verification. The overall speed of 
execution of a system being designed with this product, however, will always be limited by the 
speed of the event-driven simulator, where the major portion of the design exists. This will be 
too slow for effective hardware/software simulation." Applicants point out that Evans is 
teaching a using the "product" to allow hardware and software designers to test software 
(meaning an application) on a real hardware modeL (a physical model), but this would be slow 
for effective testing the application/integrated circuit chip design together. Again, 
"hardware/software" as used by Evans means application/integrated circuit chip design as 
explained supra. 

In conclusion, when Evans et al. states in "Unfortunately, software verification requires 
an order of magnitude more simulation patterns to verify than does hardware verification." 
Evans means testing applications "requires an order of magnitude more simulation patterns" then 
testing integrated circuit designs. Evans is not teaching that testing a physical integrated circuit 
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is faster than testing a computer simulation of that integrated circuit chip. Thus there is no 
motivation to "implement the verification in Evans by utilizing software instead of hardware" as 
the Examiner alleges. 

Second, the following apply to each argument infra. Applicants point out that in FIG. 2 
of Evans et al. the only simulation on the simulation host computer 1 18 is a simulation program 
of phoneme recognition circuitry and every element on board 75 is hardware including bus 
wrappers configured in FPGAs 74, 76, 80, 82, and 84 which are hardware. Further, the Phoneme 
circuit is loaded in the bus wrappers, so it is tested as hardware not a computer model. See steps 
310 through 316 of Evans FIG. 6. 

Applicants respectfully contend that claims 31 and 32, as amended, are not unpatentable 
ovet Evans, because Evans does not teach or suggest each and every feature of claims 3 1 and 32. 
For example, Evans does not teach any of the following claim elements: 

(1) "code representing (i) an external memory model connected to a simulated external 
memory mapped test device and to said simulated memory controller." These, if they exist in 
Evans, are hardware in Evans. 

(2) "one or more first external I/O driver models connected between said simulated I/O 
cores and said simulated external memory mapped test device." Applicants point out that "one 
or more first external I/O driver models" are not part of the Applicants "integrated circuit 
design" or Applicants "external memory mapped test device" so Evans et al. does not even teach 
the same number of components as Applicants claim Applicants find no teaching of "one or 
more first external I/O driver models" no less "one or more first external I/O driver models 
connected between said simulated I/O cores and said simulated external memory mapped test 
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device" in Evans et al. Even if these functions were taught by Evans, they would be taught as 
hardware. 

(3) "one or more second external I/O driver models connected between a simulated 
switch of said simulated external memory mapped test device and said I/O controller." 
Applicants point out that "one or more second external I/O driver models" are not part of the 
Applicants "integrated circuit design" or Applicants "external memory mapped test device" so 
Evans et. al does not even teach the same number of components as Applicants claim. Even if 
these functions were taught by Evans et al. , they would be taught as hardware. 

(4) "said test case comprising said list of computer-executable instructions for said 
simulated processor into said external memory model, said instructions describing selection of 
one or more simulated I/O cores and corresponding second external I/O models, allocation of 
pins of said I/O controller to selected simulated I/O cores and switch positions of said simulated 
switch to connect said corresponding second external I/O models to said I/O controller." There 
is no teaching in Evans et al. that the testing involves "selecting one or more simulated I/O cores 
and corresponding second external I/O models" or selecting "switch positions of said simulated 
switch to connect said corresponding second external I/O models to said I/O controller." 

(5) "connecting said simulated external memory mapped test device to said simulated I/O 
controller through said corresponding second external I/O models." Evans et al. is silent as to 
"second external I/O models." 

Based on the preceding arguments, Applicants respectfully maintain that claim 3 1 is not 
unpatentable over Evans, and that claim 3 1 is in condition for allowance. Since claims 2, 3, 5 
and 7 depend from claim 31, Applicants contend that 'claims 2, 3, 5 and 7 are likewise in 
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condition for allowance. Since claims 16, 17 and 19 depend from claim 32, Applicants contend 
that claims 16, 17 and 19 are likewise in condition for allowance. 
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CONCLUSION 

Based on the preceding arguments, Applicants respectfully believe that all pending 
claims and the entire application meet the acceptance criteria for allowance and therefore request 
favorable action. If Examiner believes that anything further would be helpful to place the 
application in better condition for allowance, Applicants invite the Examiner to contact the 
Applicants' representative at the telephone number listed below. The Director is hereby 
authorized to charge and/or credit Deposit Account 09-0456. 



-Respectfully submitted, 
FOR: 

Devins et al. 
BY: 

Dated: f^ho ° 1 /• ^/u&ln ^ 

Ja^k P. Friedman 
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Registration No.: 41,237 

Schmeiser, Olsen & Watts 
22 Century Hill Drive, Suite 302 
Latham, New York 12110 
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